home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-03-06 | 1.7 KB | 42 lines | [TEXT/GEOL] |
- Item 6832554 5-Dec-90 23:50PST
-
- From: D0416 Futuresoft System Design,PRT
-
- To: DAWSON.M Dawson, Mark
-
- cc: GER.XSE0096 Germany - Ciechowski Computer,IDV
- MACAPP.TECH$ MacApp Technical
-
- Sub: RE[2] Window closed?
-
- Mark,
-
- >I don't think MacApp uses fChangeCount for anythingbut a true (>0) or false
- >(0)
- >value (it doesn't seem to in its TDocument::Close() procedure). It also
- >doesn't seem to reset it after a save (meaning that you'll have to add a
- >this->fChangeCount = 0 in your TDocument::Save(), if you want the "Save" to
- >grey out after you save a document, but before any new information has been
- >added to that document).
-
- MacApp DOES, in most cases, automatically maintain the fChangeCount including
- after (actually during) Save. It also automatically maintains fChangeCount for
- Doing, ReDoing and UnDoing commands (if the command’s fCausesChange is TRUE) as
- well as Reverting documents.
-
- I have found it is only necessary to set fChangeCount when I am modifying the
- document’s saved data or state directly without instantiating a command to do
- the task.
-
- I’m converting the few places that I do modify a doc’s data or state to doing
- it via a TCommand subclass instead of directly. This will make things much
- easier to incorporate some System 7 features especially AppleEvents. There is
- also more memory available at aCommand.DoIt time because MacApp unloads all
- unncessary segments before executing commands. MacApp in the current
- 2.0{.whatever} itself has changed many functions since alpha and beta to do
- almost all things through commands including “Quit”. Hmm…
-
- Oh well, take care,
- -TKen_Addison.OuttaHereCommand
-
-